XxZ0
Background: Know: VACM Recognize: Text in figure: securityModel, securityName, contextName, securityLevel, groupName, viewName, viewType, object, variableName, vacmSecurityToGroupTable, vacmContextTable, vacmAccessTable vacmViewFamilyTree Access Control module Overview of isAccessAllowed Process This section describes the procedures followed by an Access Control module that implements the View-based Access Control Model when checking access rights as requested by an application (for example a Command Responder or a Notification Originator application).The abstract service primitive is: statusInformation = -- success or errorIndication isAccessAllowed( securityModel -- Security Model in use securityName -- principal who wants access securityLevel -- Level of Security viewType -- read, write, or notify view contextName -- context containing variableName variableName -- OID for the managed object ) Overview of isAccessAllowed Process 1) Inputs to the isAccessAllowed service are: (a) securityModel -- Security Model in use (b) securityName -- principal who wants to access © securityLevel -- Level of Security (d) viewType -- read, write, or notify view (e) contextName -- context containing variableName (f) variableName -- OID for the managed object -- this is made up of: - object-type (m) - object-instance (n) ------------------------------------------------------------------- 2) The partial "who"(1), represented by the securityModel (a) and the securityName (b), are used as the indices (a,b) into the vacmSecurityToGroupTable to find a single entry that produces group, represented by groupName (x). ------------------------------------------------------------------- 3) The "where" (2), represented by the contextName (e), the "who", represented by the groupName (x) from the previous step, and the"how" (3), represented by securityModel (a) and securityLevel ©, are used as indices (e,x,a,c) into the vacmAccessTable to find a single entry that contains three MIB views. ------------------------------------------------------------------- ) The "why" (4), epresented by the viewType (d), is used to select the proper MIB view, represented by a viewName (y), from the vacmAccessEntry selected in the previous step. This viewName (y) is an index into the vacmViewTreeFamilyTable and selects the set of entries that define the variableNames which are included in or excluded from the MIB view identified by the viewName (y). ------------------------------------------------------------------- 5) The "what" (5) type of management data and "which" (6) particular instance, represented by the variableName (f), is then checked to be in the MIB view or not, e.g., the yes/no decision (z). = 3.2. Processing the isAccessAllowed 3415Service Request] This section describes the procedure followed by an Access Control module that implements the View-based Access Control Model whenever it receives an isAccessAllowed request. 1) The vacmContextTable is consulted for information about the SNMP context identified by the contextName. If information about this SNMP context is absent from the table, then an errorIndication (noSuchContext) is returned to the calling module. 2) The vacmSecurityToGroupTable is consulted for mapping the securityModel and securityName to a groupName. If the information about this combination is absent from the table, then an errorIndication (noGroupName) is returned to the calling module. 3) The vacmAccessTable is consulted for information about the groupName, contextName, securityModel and securityLevel. If information about this combination is absent from the table, then an errorIndication (noAccessEntry) is returned to the calling module. 4) a) If the viewType is "read", then the read view is used for checking access rights. b) If the viewType is "write", then the write view is used for checking access rights. c) If the viewType is "notify", then the notify view is used for checking access rights. If the view to be used is the empty view (zero length viewName) then an errorIndication (noSuchView) is returned to the calling module. 5) a) If there is no view configured for the specified viewType, then an errorIndication (noSuchView) is returned to the calling module. b) If the specified variableName (object instance) is not in the MIB view, then an errorIndication (notInView) is returned to the calling module. Otherwise, c) The specified variableName is in the MIB view. A statusInformation of success (accessAllowed) is returned to the calling module. http://www.rfc-ref.org/RFC-TEXTS/3415/chapter3.html Category:All